Historic advances in computer technology have made it economical for individual users to have their own computing system, which caused the proliferation of the Personal Computer (PC). Continued advances of this computer technology have made these personal computers very powerful but also complex and difficult to manage. For this and other reasons there is a desire in many workplace environments to separate the display and user interface devices including the keyboard, mouse and other peripheral devices from the storage and application processing parts of the computing system. In this configuration, the user interface devices are physically located at the desktop, while the processing and storage components of the computer are placed in a central location. The user interface devices are then connected to the processor and storage components with some method of communication.
There are two existing categories of methods for enabling the physical separation of USB peripheral devices from processing software. The first category includes methods using high level software bridging techniques and the second category includes methods using low level physical bridging.
FIG. 1 is a prior art illustration of a standard USB stack architecture as found in host system 150, an example of which is a standard PC environment without any separation between a computing system and its USB bus and devices. USB software drivers 120 are comprised of USB device driver 100, for example a USB mouse driver which sends high-level USB I/O commands to a set of peripheral bus drivers 102, comprised of core driver 104 and host controller (HC) driver 106. Core driver 104 converts the high level USB I/O commands into USB Request blocks 160 which are communicated to host controller driver (HCD) 106. HCD 106 interprets the USB request blocks and uses memory-based HC control structures 130 in host memory 108. These structures include a standardized set of descriptor lists and host controller communications area (HCCA) to control the operation of peripheral bus host controller 110, which in turn provides USB connection 112 to USB device 114. In a USB embodiment, peripheral bus host controller 110 may also be referred to as a USB host controller. Other embodiments such as an IEEE 1394 host controller controlling an IEEE 1394 peripheral bus are also possible.
FIG. 2 illustrates a prior art approach that illustrates a bridging architecture encompassing the high-level software bridging category of methods. In the example, host system 250 is connected to remote system 260 by some form of network. An example of such a networked system is a host computer server connected to a remote thin client. Referring to FIG. 2, USB device driver 270 sends I/O commands to host bridged peripheral bus drivers 200, comprising core driver 204 and virtual HCD 202. Note that USB device driver 270 and core driver 204 are the same as the equivalent components in FIG. 1. Host bridged peripheral bus drivers 200 communicates USB request blocks 222 over physical separation link 220 to remote bridged peripheral bus drivers 230 of a remote system. Physical separation link 220 may be a standard network connection such as an IP/Ethernet connection. Remote bridged peripheral bus drivers 230 include stub driver 206, core driver 208 and HCD 209 which uses memory-based HC control structures 234 in remote memory 232 to communicate with a remotely located peripheral bus host controller 210 (where remotely located peripheral bus host controller 210 has the same function as peripheral bus host controller 110 in FIG. 1). Depending on the remote address environment, memory-based HC control structures 234 in remote memory 232 may use the same or different addressing to non-bridged memory-based HC control structures 130 in host memory 108 shown in FIG. 1. Remote peripheral bus host controller 210 communicates with remote USB device 214 over standard USB bus 212 as before (where remote USB bus 212 and device 214 are identical to USB bus 112 and USB device 114 respectively). Products such as Microsoftís RDP, AnywhereUSB and others bridge the USB signals at a software driver layer using software bridging methods similar to or the same as example FIG. 2. These methods require special virtualized peripheral bus drivers (i.e. host bridged peripheral bus drivers 200) compared to those of a standard PC using peripheral bus drivers 102. Furthermore, these methods typically mandate that the remote system (e.g. a thin client) maintain its own lightweight operating system to support remote bridged peripheral bus drivers 230. The need for specialized host system drivers and remote software results in increased complexity and maintenance requirements over a standard PC system which defeats many of the objectives related to remote user interface architectures. Furthermore, the need for matching host and remote drivers limits interoperability between USB devices and host systems, further limiting the appeal of software bridging solutions.
The second category of methods for separating USB devices includes transport layer extension techniques as provided by USB cable replacement products or KVM extension systems. These products use host and remote hardware modules for communicating equivalent USB bus signals over wired or wireless links. In the case of wired links, USB signals are typically communicated over dedicated CAT5 cabling between a host module connected to the USB port of a host computer and a remote module connected to a USB device. Icronís ExtremeUSB is an example of a CAT5 extension that enables a limited separation between a remote user interface and host system. The major drawback of transport layer solutions are the limitations imposed by additional cabling. The addition of non-standardized cabling to corporate LAN infrastructure adds to capital costs and increases the maintenance burden. Furthermore, unless elaborate and expensive optical or wireless transceivers are used, USB peripherals may only operate correctly over limited distance due to bus timing constraints (such as time critical acknowledgement protocols) which also limits full compliance with the USB protocol.
In summary, existing methods of bridging USB peripheral interfaces require significant complexity at the remote user interface, and have reduced interoperability or distance and performance limitations. System costs and maintenance overheads are increased which defeats the objective of centralized computing. Therefore, there is a heartfelt need for a better method for providing USB and other peripheral connections between a host processor and a remote user interface that meets the economic objectives of centralized computer processing without the limitations described above.